Field
Embodiments generally relate to security and control and in particular, to entitlement security and control, using metadata.
Description
Many attempts have been made to secure user access to, for example, an application and to more closely monitor and manage such access. However, methods and apparatus available today fail to separate entitlement from access, and primarily rely on the “access” part of a security system rather than focusing on the “entitlement” part. By focusing primarily on the access part of the security system, the methods and apparatus available today do not provide the level or type of security and protection needed against hackers, terminated employees or other such individuals, groups, or organizations. For example, a hacker typically obtains access to a system (by hacking), but may never obtain entitlement. Similarly, for example, a terminated employee may continue to access the company's email despite having been terminated, i.e., not having entitlement permission.
Furthermore, methods and apparatus available today do not have rules, regulations, or roles at the entitlement level to filter users, customers, or applicants before they are granted access. Such methods and apparatus do not classify data in terms of security, importance, urgency, confidentiality, government, community and organization rules and regulations, and other such matters, and are manual and rely on the expectation that someone or some group within the company is security-aware and can flawlessly filter people when grating access permissions. Additionally, methods and apparatus available today do not use metadata.
Typically, as illustrated in FIG. 1, a user 102 places an access permission request 104 with a company to gain access to a protected application 118. An administrator 106 reviews the request 104, and if the request is granted, the administrator may update an access control list (ACL) 108 with user information. However, many rules, regulations, laws, policies, security classifications, and names are likely to be not updated and consequently, ACL 108 is not likely to be content-aware, security-aware, classified, or fully updated, and, is likely to be unable to perform a real-time, fast, informed, and accurate check of access requests 104. Such process is slow, manual, tedious, labor-intensive, and inaccurate, if various changes are not quickly adopted or known, and is based on out-of-date information. Upon reviewing, the user 102 is either rejected 112 or accepted 114. If approved, the user's 102 name and/or other designations are placed in the ACL 108 and the user 102 may access a protected application 118.
Examples of access-based security and control systems include Access360 by International Business Machines (IBM), RAFC, which is a mainframe access control system, Windows Active Directory, by Microsoft Corporation, is an access control or management system which is known to coordinate Windows access control lists. Other examples included Discretionary Access Control (DAC) account permissions, Mandatory Access Control (MAC) system, Role-Based Access Control (RBAC), which is no more than a pre-packed form of MAC, and a Lattice-Based Access Control (LBAC), which is a combination of RBAC and DAC.
None of the methods or apparatus available today is entitlement-based, metadata driven, security-aware, dynamically updated, or fully automated. Methods and apparatus available today do not provide real-time review of user requests or tracking events or keeping of an audit trail. Furthermore, methods and apparatus available today fail to provide an entitlement-based, metadata driven, security-aware, dynamically updated, or fully automated way of removing access, since there may not be a way of remembering or knowing why the entitlement and access were granted in the first place.